Frigørelse af ydeevne: En dybdegående undersøgelse af WebGL Clustered Forward Rendering og optimering af lysindeksering

I verdenen af realtids 3D-grafik på nettet har rendering af adskillige dynamiske lys altid været en betydelig ydeevneudfordring. Som udviklere stræber vi efter at skabe rigere og mere fordybende scener, men hver ekstra lyskilde kan eksponentielt øge de beregningsmæssige omkostninger og presse WebGL til dets grænser. Traditionelle renderingsteknikker tvinger ofte et vanskeligt valg: ofre visuel kvalitet for ydeevne, eller acceptere lavere billedhastigheder. Men hvad hvis der var en måde at få det bedste fra begge verdener?

Indtast Clustered Forward Rendering, også kendt som Forward+. Denne kraftfulde teknik tilbyder en sofistikeret løsning, der kombinerer enkelheden og materialefleksibiliteten ved traditionel forward rendering med lyseffektiviteten af deferred shading. Det giver os mulighed for at rendere scener med hundredvis, eller endda tusindvis, af dynamiske lys, mens vi opretholder interaktive billedhastigheder.

Denne artikel giver en omfattende udforskning af Clustered Forward Rendering i en WebGL-kontekst. Vi vil dissekere de grundlæggende koncepter, fra underopdeling af view frustum til culling af lys, og fokusere intenst på den mest kritiske optimering: lysets indekseringsdatapipeline. Dette er den mekanisme, der effektivt kommunikerer, hvilke lys der påvirker hvilke dele af skærmen fra CPU'en til GPU'ens fragment shader.

Renderingslandskabet: Forward vs. Deferred

For at forstå, hvorfor clustered rendering er så effektivt, skal vi først forstå begrænsningerne ved de metoder, der gik forud for det.

Traditionel Forward Rendering

Dette er den mest ligetil renderingstilgang. For hvert objekt behandler vertex shader dets vertices, og fragment shader beregner den endelige farve for hver pixel. Når det kommer til belysning, looper fragment shader typisk gennem hvert eneste lys i scenen og akkumulerer dets bidrag. Kerneproblemet er dets dårlige skalering. De beregningsmæssige omkostninger er omtrent proportional med (Antal Fragmenter) x (Antal Lys). Med blot et par dusin lys kan ydeevnen styrtdykke, da hver pixel redundant tjekker hvert lys, selv dem der er milevidt væk eller bag en væg.

Deferred Shading

Deferred Shading blev udviklet til at løse netop dette problem. Det afkobler geometri fra belysning i en to-pass proces:

1. Geometri Pass: Scenens geometri renderes til flere fuldskærmsteksturer, der kollektivt er kendt som G-bufferen. Disse teksturer gemmer data som position, normaler og materialegenskaber (f.eks. albedo, ruhed) for hver pixel.
2. Lys Pass: En fuldskærms quad tegnes. For hver pixel sampler fragment shader G-bufferen for at rekonstruere overfladens egenskaber og beregner derefter belysning. Den vigtigste fordel er, at belysning kun beregnes én gang pr. pixel, og det er let at bestemme, hvilke lys der påvirker den pixel baseret på dens verdensposition.

Selvom det er meget effektivt til scener med mange lys, har deferred shading sit eget sæt af ulemper, især for WebGL. Det har høje hukommelsesbåndbreddekrav på grund af G-bufferen, kæmper med gennemsigtighed (hvilket kræver et separat forward rendering pass) og komplicerer brugen af anti-aliasing teknikker som MSAA.

Sagen for en mellemvej: Forward+

Clustered Forward Rendering giver et elegant kompromis. Det bevarer den enkelt-pass natur og materialefleksibiliteten ved forward rendering, men inkorporerer et præ-processeringstrin for dramatisk at reducere antallet af lysberegninger pr. fragment. Det undgår den tunge G-buffer, hvilket gør det mere hukommelsesvenligt og kompatibelt med gennemsigtighed og MSAA ud af boksen.

Grundlæggende koncepter i Clustered Forward Rendering

Den centrale idé med clustered rendering er at være smartere omkring, hvilke lys vi tjekker. I stedet for at hver pixel tjekker hvert lys, kan vi præ-bestemme, hvilke lys der er tæt nok på til muligvis at påvirke en region af skærmen, og få pixlerne i den region kun til at tjekke de lys.

Dette opnås ved at underopdele kameraets view frustum i et 3D-gitter af mindre volumener kaldet klynger (eller tiles).

Den overordnede proces kan opdeles i fire hovedstadier:

• 1. Klynge Gitter Oprettelse: Definer og konstruer et 3D-gitter, der partitionerer view frustum. Dette gitter er fast i view space og bevæger sig med kameraet.
• 2. Lys Tildeling (Culling): For hver klynge i gitteret skal du bestemme en liste over alle lys, hvis påvirkningsvolumener krydser den. Dette er det afgørende culling-trin.
• 3. Lys Indeksering: Dette er vores fokus. Vi pakker resultaterne af lys tildelingstrinet ind i en kompakt datastruktur, der effektivt kan sendes til GPU'en og læses af fragment shaderen.
• 4. Shading: Under hovedrendering passet bestemmer fragment shaderen først, hvilken klynge den tilhører. Den bruger derefter lys indekseringsdataene til at hente listen over relevante lys for den klynge og udfører lysberegninger *kun* for det lille undersæt af lys.

Dybdegående: Opbygning af klynge gitteret

Grundlaget for teknikken er et velstruktureret gitter. De valg, der træffes her, påvirker både culling effektivitet og ydeevne direkte.

Definition af gitterdimensioner

Gitteret er defineret af dets opløsning langs X-, Y- og Z-akserne (f.eks. 16x9x24 klynger). Valget af dimensioner er et kompromis:

• Højere opløsning (flere klynger): Fører til tættere og mere præcis lys culling. Færre lys vil blive tildelt pr. klynge, hvilket betyder mindre arbejde for fragment shaderen. Det øger dog overhead for lys tildelingstrinet på CPU'en og hukommelsesfodaftrykket af klynge datastrukturerne.
• Lavere opløsning (færre klynger): Reducerer CPU-siden og hukommelses overhead, men resulterer i grovere culling. Hver klynge er større, så den vil krydse med flere lys, hvilket fører til mere arbejde i fragment shaderen.

En almindelig praksis er at binde X- og Y-dimensionerne til skærmens billedformat, for eksempel at opdele skærmen i 16x9 tiles. Z-dimensionen er ofte den mest kritiske at tune.

Logaritmisk Z-slicing: En kritisk optimering

Hvis vi opdeler frustums dybde (Z-akse) i lineære skiver, støder vi på et problem relateret til perspektivprojektion. En enorm mængde geometriske detaljer er koncentreret tæt på kameraet, mens objekter langt væk optager meget få pixels. En lineær Z-split ville skabe store, upræcise klynger nær kameraet (hvor præcision er mest nødvendig) og bittesmå, spildende klynger i det fjerne.

Løsningen er logaritmisk (eller eksponentiel) Z-slicing. Dette skaber mindre, mere præcise klynger nær kameraet og gradvist større klynger længere væk, hvilket justerer klyngefordelingen med den måde, perspektivprojektion fungerer på. Dette sikrer et mere ensartet antal fragmenter pr. klynge og fører til meget mere effektiv culling.

En formel til at beregne dybden `z` for den i-te skive ud af `N` samlede skiver, givet det nære plan `n` og det fjerne plan `f`, kan udtrykkes som:

Denne formel sikrer, at forholdet mellem fortløbende skivedybder er konstant, hvilket skaber den ønskede eksponentielle fordeling.

Sagets kerne: Lys Culling og Indeksering

Det er her magien sker. Når vores gitter er defineret, skal vi finde ud af, hvilke lys der påvirker hvilke klynger, og derefter pakke disse oplysninger til GPU'en. I WebGL udføres denne lys culling logik typisk på CPU'en ved hjælp af JavaScript for hver frame, hvor lys eller kameraet bevæger sig.

Lys-klynge krydsningstest

Processen er konceptuelt enkel: loop gennem hvert lys og test det for krydsning mod hver klynges bounding volumen. Bounding volumen for en klynge er selv en frustum. Almindelige tests inkluderer:

• Punkt Lys: Behandles som kugler. Testen er en kugle-frustum krydsning.
• Spot Lys: Behandles som kegler. Testen er en kegle-frustum krydsning, som er mere kompleks.
• Retningsbestemt Lys: Disse betragtes ofte som at påvirke alt, så de håndteres typisk separat og er ikke inkluderet i culling-processen.

Det er afgørende at udføre disse tests effektivt. Efter dette trin har vi en mapping, måske i et JavaScript array af arrays, som: clusterLights[clusterId] = [lightId1, lightId2, ...].

Datastrukturudfordringen: Fra CPU til GPU

Hvordan får vi denne lysliste pr. klynge til fragment shaderen? Vi kan ikke bare sende et array af variabel længde. Shaderen har brug for en forudsigelig måde at slå disse data op på. Det er her Global Light List og Light Index List tilgangen kommer ind. Det er en elegant metode til at udjævne vores komplekse datastruktur til GPU-venlige teksturer.

Vi opretter to primære datastrukturer:

1. En klyngeinformationsgittertekstur: Dette er en 3D-tekstur (eller en 2D-tekstur, der emulerer en 3D-tekstur), hvor hver texel svarer til en klynge i vores gitter. Hver texel gemmer to vitale informationer:
   • En forskydning: Dette er startindekset i vores anden datastruktur (den globale lysliste), hvor lysene for denne klynge begynder.
   • Et antal: Dette er antallet af lys, der påvirker denne klynge.
2. En global lysliste tekstur: Dette er en simpel 1D-liste (gemt i en 2D-tekstur), der indeholder en sammenkædet sekvens af alle lysindekser for alle klynger.

Visualisering af dataflowet

Lad os forestille os et simpelt scenario:

• Klynge 0 påvirkes af lys med indekser [5, 12].
• Klynge 1 påvirkes af lys med indekser [8, 5, 20].
• Klynge 2 påvirkes af lys med indeks [7].

Global lysliste: [5, 12, 8, 5, 20, 7, ...]

Klyngeinformationsgitter:

• Texel for klynge 0: { offset: 0, count: 2 }
• Texel for klynge 1: { offset: 2, count: 3 }
• Texel for klynge 2: { offset: 5, count: 1 }

Implementering i WebGL & GLSL

Lad os nu forbinde koncepterne til koden. Implementeringen involverer en JavaScript-del til culling og dataforberedelse og en GLSL-del til shading.

Dataoverførsel til GPU'en (JavaScript)

Efter at have udført lys culling på CPU'en, vil du have dine klyngegitterdata (forskydnings-/antalspar) og din globale lysliste. Disse skal uploades til GPU'en hver frame.

1. Pak og upload klyngedata: Opret en `Float32Array` eller `Uint32Array` til dine klyngedata. Du kan pakke forskydningen og antallet for hver klynge ind i RG-kanalerne i en tekstur. Brug `gl.texImage2D` til at oprette eller `gl.texSubImage2D` til at opdatere en tekstur med disse data. Dette vil være din klyngeinformationsgittertekstur.
2. Upload global lysliste: Udjævn på samme måde dine lysindekser til en `Uint32Array`, og upload den til en anden tekstur.
3. Upload lysegenskaber: Alle lysdata (position, farve, intensitet, radius osv.) skal gemmes i en stor tekstur eller et Uniform Buffer Object (UBO) for hurtige, indekserede opslag fra shaderen.

Fragment Shader Logikken (GLSL)

Fragment shaderen er der, hvor ydelsesforbedringerne realiseres. Her er den trin-for-trin logik:

Trin 1: Bestem fragmentets klyngeindeks

Først skal vi vide, hvilken klynge det aktuelle fragment falder ind i. Dette kræver dets position i view space.

            
// Uniforms der giver gitterinformation
uniform vec3 u_gridDimensions; // f.eks. vec3(16.0, 9.0, 24.0)
uniform vec2 u_screenDimensions;
uniform float u_nearPlane;
uniform float u_farPlane;

// Funktion til at få Z-skiveindekset fra view-space dybde
float getClusterZIndex(float viewZ) {
  // viewZ er negativ, gør den positiv
  viewZ = -viewZ;
  // Det inverse af den logaritmiske formel, vi brugte på CPU'en
  float slice = floor(log(viewZ / u_nearPlane) / log(u_farPlane / u_nearPlane) * u_gridDimensions.z);
  return slice;
}

// Hovedlogik til at få 3D-klyngeindekset
vec3 getClusterIndex() {
  // Få X- og Y-indeks fra skærmkoordinater
  float clusterX = floor(gl_FragCoord.x / u_screenDimensions.x * u_gridDimensions.x);
  float clusterY = floor(gl_FragCoord.y / u_screenDimensions.y * u_gridDimensions.y);
  
  // Få Z-indeks fra fragmentets view-space Z-position (v_viewPos.z)
  float clusterZ = getClusterZIndex(v_viewPos.z);

  return vec3(clusterX, clusterY, clusterZ);
}

            

              
                Copy
              
            
          

Trin 2: Hent klyngedata

Ved hjælp af klyngeindekset sampler vi vores klyngeinformationsgittertekstur for at få forskydningen og antallet for dette fragments lysliste.

            
uniform sampler2D u_clusterTexture; // Tekstur der gemmer forskydning og antal

// ... i main() ...
vec3 clusterIndex = getClusterIndex();
// Udjævn 3D-indeks til 2D-teksturkoordinat om nødvendigt
vec2 clusterTexCoord = ...; 

vec2 lightData = texture2D(u_clusterTexture, clusterTexCoord).rg;
int offset = int(lightData.x);
int count = int(lightData.y);

            

              
                Copy
              
            
          

Trin 3: Loop og akkumuler belysning

Dette er det sidste trin. Vi udfører en kort, afgrænset loop. For hver iteration henter vi et lysindeks fra den globale lysliste, bruger derefter det indeks til at få lysets fulde egenskaber og beregner dets bidrag.

            
uniform sampler2D u_globalLightIndexTexture;
uniform sampler2D u_lightPropertiesTexture; // UBO ville være bedre

vec3 finalColor = vec3(0.0);

for (int i = 0; i < count; i++) {
  // 1. Få indekset for det lys, der skal behandles
  int lightIndex = int(texture2D(u_globalLightIndexTexture, vec2(float(offset + i), 0.0)).r);

  // 2. Hent lysets egenskaber ved hjælp af dette indeks
  Light currentLight = getLightProperties(lightIndex, u_lightPropertiesTexture);

  // 3. Beregn dette lys' bidrag
  finalColor += calculateLight(currentLight, surfaceProperties, viewDir);
}

            

              
                Copy
              
            
          

Og det er det! I stedet for en loop, der kører hundredvis af gange, har vi nu en loop, der muligvis kører 5, 10 eller 30 gange, afhængigt af lys densiteten i den specifikke del af scenen, hvilket fører til en monumental ydeevneforbedring.

Avancerede optimeringer og fremtidige overvejelser

• CPU vs. Compute: Den primære flaskehals ved denne teknik i WebGL er, at lys culling sker på CPU'en i JavaScript. Dette er single-threaded og kræver en datasynkronisering med GPU'en hver frame. Ankomsten af WebGPU er en game-changer. Dets compute shaders vil tillade hele klyngeopbygningen og lys culling processen at blive aflæsset til GPU'en, hvilket gør den parallel og størrelsesordener hurtigere.
• Hukommelseshåndtering: Vær opmærksom på den hukommelse, der bruges af dine datastrukturer. For et 16x9x24 gitter (3.456 klynger) og et maksimum på f.eks. 64 lys pr. klynge, kan den globale lysliste potentielt indeholde 221.184 indekser. Tuning af dit gitter og indstilling af et realistisk maksimum for lys pr. klynge er essentielt.
• Tuning af gitteret: Der er ikke noget enkelt magisk tal for gitterdimensioner. Den optimale konfiguration afhænger i høj grad af din scenes indhold, kameraadfærd og målhardware. Profilering og eksperimentering med forskellige gitterstørrelser er afgørende for at opnå maksimal ydeevne.

Konklusion

Clustered Forward Rendering er mere end bare en akademisk kuriositet; det er en praktisk og kraftfuld løsning på et betydeligt problem i realtids webgrafik. Ved intelligent at underopdele view space og udføre en meget optimeret lys culling og indekseringstrin, bryder det det direkte link mellem lys antal og fragment shader omkostninger.

Selvom det introducerer mere kompleksitet på CPU-siden sammenlignet med traditionel forward rendering, er ydeevnegevinsten enorm, hvilket muliggør rigere, mere dynamiske og visuelt overbevisende oplevelser direkte i browseren. Kernen i dets succes ligger i den effektive lys indekseringspipeline - broen, der transformerer et komplekst rumligt problem til en simpel, afgrænset loop på GPU'en.

Efterhånden som webplatformen udvikler sig med teknologier som WebGPU, vil teknikker som Clustered Forward Rendering kun blive mere tilgængelige og performante, hvilket yderligere udvisker grænserne mellem native og webbaserede 3D-applikationer.